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‘This  report  covers  the  first  six  months  of  a one-year  research  and\ 
development  program  directed  towards  the  design  and  incorporation  ^ 
of  an  Adaptive  Information  Selection  scheme  used  within  a (^3) environment 
with  special  emphasis  on  the  Tactical  Combat  Operations(TC^  system. 

A multi-attribute  evaluation  model  is  used  to  determine  the  proper 
dissemination  of  TCO  messages.  The  development  of  an  in-house  simulation 
using  the  existing  Tactical  and  Negotiations  Game  is  discussed.  A background 


Training  Algorithm 

Marine  Corps  Tactical  Systems  Support 
Activity  (MCTSSA) 

Marine  Tactical  Command  and  Control 
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— > rationale  is  given  to  present  the  need  for  such  an  aid.  The  MTACCS 

Interim  Test  Facility  within  which  the  Adaptive  Information  Selector  will 
eventually  be  implemented;  is  discussed  in  detail.  An  analysis  was 
performed  to  determine  the  attributes  available  from  the  messages  and 
message  headers  resident  in  the  MTACCS  Interim  Test  Facility  Database.  A 
training  scheme  is  developed  tailored  to  the  actual  operator  actions 
performed  during  exercises  at  the  Test  Facility.  The  principal  functions 
making  up  the  AIS  are  defined  and  their  interfaces  shown  in  a functional 
information  flow  diagram.  The  database  management  system  used  at  the 
MTACCS  Interim  Test  Facility  is  discussed  including  the  definition  of  some 
of  its  data  structures.  Finally,  an  estimated  burden  of  the  AIS  as  it 
will  be  implemented  on  the  MTACCS  Interim  Test  Facility  is  presented. 
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1 . SUMMARY 


1.1  Objectives 

This  report  covers  the  first  portion  of  a one-year  program  of 
research,  development,  and  software  design.  The  program  is  directed 
toward  (a)  the  development  of  a general  purpose  methodology  of  adaptive 
information  selection  (AIS)  for  C3  systems;  (b)  the  development  of 
software  and  procedures  for  AIS  implementation  in  specific  C3  sytems, 
e.g.,  the  Marine's  Tactical  Combat  Operations  (TCO)  system.  Specific 
objectives  of  the  program  included: 

(1)  An  analysis  of  TCO  operations  and  identification  of  the 
specific  functions  to  be  performed  by  the  AIS. 

(2)  Development  of  the  overall  structure  of  the  AIS  model, 
specification  of  principal  functions,  formulations  of  data 
structures,  and  definition  of  model  attributes  accessible 
from  the  simulated  TCO  messages  resident  in  the  data  base 
of  the  Marine  Tactical  Command  and  Control  System  (MTACCS) 
Interim  Test  Facility. 

(3)  A preliminary  estimate  of  the  operating  burden  of  the  AIS. 

(4)  A review  and  analysis  of  the  evaluation  measures  planned  by 
the  Marine  Corps  Tactical  Systems  Support  Activity  (MCTSSA) 
for  the  coming  MTACCS  Interim  Test  Facility  exercises  in  the 
light  of  AIS  evaluation  procedures. 

These  objectives  were  met  by  reconciling  and  integrating  the  Adaptive 
Information  Selection  Concept  within  the  framework  provided  by  TCO  and 
Interim  Facility-related  documents.  In  particular,  the  present  adaptive 
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estimator  previously  developed  for  computer  aiding  of  dynamic  decision 
processes.  This  estimator  has  been  modified  to  train  in  a simulated  TCO 
environment  on  the  Marine's  Interim  Test  Facility. 

The  program  is  being  conducted  with  the  continuing  close 
cooperation  and  support  of  the  Marine  Corps  Tactical  Systems  Support 
Activity  (MCTSSA),  Marine  Corps  Base,  Camp  Pendleton,  California.  MCTSSA 
will  provide  battalion  test  scenarios,  access  to  their  Interim  Test 
Facility,  and  Marine  evaluation  personnel.  Selected  support  functions  will 
be  developed  and  evaluated  within  the  framework  of  the  Tactical  Combat 
Operations  (TCO)  system. 

1 .2  Technical  Approach 

1.2.1  Support  Requirements.  Modern  tactical  warfare  presents  a complex 
and  dynamic  environment,  involving  computerized  weapons  systems,  fast 
ground  and  air  vehicles,  and,  most  important,  a surplus  of  incoming 
information.  The  battlefield  of  the  mid-1980's  will  be  characterized  by 
a combat  intensity  never  before  seen.  As  expressed  graphically  by 
MCTSSA  (1977): 


attribute  evaluation  model  utilizes  a trainable  utility  (evaluation)  j 


"The  proliferation  of  sophisticated  weapons  and  equipment  am^fiq 
the  great  powers  as  well  as  their  client  states  will  blur  anu 
distinction  between  low  ar.d  mid~intensitu  conflicts.  The 
introduction  of  precision  and  guided  munitions  will  gix'>e  the 
individual  infantr^r'Kin  the  destructive  powers  foryxerli)  possessed 
only  by  crew-sen>ea  weapons.  In  additiori,  speed  of  rKj'vuivr  will 
be  greatly  enhanced  by  use  of  armored/motcrized/mechani sed  forces. 
Adding  to  the  confusion  inherent  in  such  an  environment  will  be 
the  voluminous  amounts  of  data  provided  by  complex  infoimyxiion 
collection,  processing,  and  reporting  systems". 


The  performance  of  tactical  commanders  in  such  an  environment  is  highly 
dependent  on  their  decision  making  behavior,  in  terms  of  their  ability 
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to  generate,  evaluate,  and  select  among  alternative  courses  of  action  --  for 
example,  to  allocate  weapon  assets,  countermeasures,  etc.,  while 
considering  the  specific  situational  constraints  and  payoffs.  Decision 
making  behavior  is,  in  turn,  largely  dependent  on  the  commander's  ability 
to  manage  the  ever-increasing  information  load  under  conditions  of  severe 
time  constraints  and  environmental  uncertainty. 

"Ths  cornander'a  infcvnyation  requirements  on  this  modern,  fast- 
moving,  lethal  battlefield  inll  gi'eatly  increase.  Current  methods 
are  insufficient  in  providing  him  vith  timely,  acouiMte,  and 
complete  infomation  tn  a usable  form.  The  time  compression 
factor  will  be  such  that  the  corrmander  will  need  the  fastest 
possible  presentation  of  required  infomation  to  allow  the 
maximum  time  for  decision  makingi  the  highlighting  of  critical 
items  presented  in  an  easily  understood  and  useful  foimat;  and 
the  suppression  of  exti'aneous  items". 

Computer  support  of  the  information  management  and  decision  making 
function  appears  to  be  the  most  promising  path  to  performance  improvement. 

"Automation  is  being  introduced  into  virtually  every  functional 
area  of  corrx2nd  and  control:  fii'e  support,  air  control, 
intelligence,  logistics,  ayid  manpower.  In  the  19S0  time  fi\w 
the  unprecedented  volume  of  information  from  these  systems  that 
is  pertinent  to  tactical  decisions  cannot  be  received  ay:d 
processed  at  operation  centers  without  the  aid  of  automation". 

An  issue  of  particular  concern  is  computer  support  of  small  units, 
i.e.,  at  the  battalion  and  company  levels.  Currently,  these  levels  of 
coimiand  do  not  have  any  organized  automated  support  for  information 
management  or  decision  aiding.  Since  battalion  and  companies  furnish 
major  inputs  to  high-level  C3  systems,  any  errors  and  delays  on  their  part 
may  lead  to  significant  reduction  of  overall  command  effectiveness.  Thus, 
the  small  unit  commander  is  both  in  need  of  help  and  pivotally  important 
to  overall  system  performance.  Accordingly,  techniques  for  alleviating 
some  of  this  problems  have  a high  payoff  potential.  In  this  program,  the 
focus  is  on  the  Marine  battalion  commander. 


1-3 


t 


1.2.2  Automated  Information  Management.  The  goal  of  the  proposed  12- 
month  program  is  to  apply  Perceptronics'  AIS  methodology  to  the  Marine 
TCO  system  as  represented  on  the  MTACCS  Interim  Test  Facility.  The  AIS 
will  aid  TCO  operations  by  managing  transfer  of  critical  information  among 
front-line  sources,  tactical  data  bases,  and  system  users.  In  brief, 
the  AIS  functions  by  characterizing  messages  along  a measurable  set  of 
attributes.  The  attributes  comprise  such  factors  as  message  content, 
area,  age,  accuracy,  and  geographic  locale.  The  information  selection 
policies  of  different  users  are  then  modeled  for  each  tactical  situation 
as  distinct  vectors  of  attribute  weights.  The  set  of  multi-attribute 
models  inherent  in  the  AIS  serve  the  following  functions: 

(1)  Automatically  routing  messages  from  sources  to  various  users. 

(2)  Automatically  reprioritizing  the  queue  of  messages  as  command 
situations  change. 

(3)  Scanning  the  data  base  for  critical  situation  relevant  data. 

Attribute  weights  are  estimated  adaptively  from  observed  user  behavior. 
This  methodology  is  discussed  in  detail  in  Chapter  2. 


2.  TECHNICAL  BACKGROUND 


2.1  Overview 
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Automated  information  management  in  support  of  C3  functions  of 
small  Marine  units  focuses  on  individualized  evaluation  and  distribution 
of  information.  Multi-attribute  models  are  used  to  take  into  account 
data  characteristics,  operator  responsibilities,  and  situational  demands. 
This  chapter  describes  the  tactical  decision  making  environment,  discusses 
a methodology  for  automated  infomation  management,  and  presents  plans 
for  experimental  validation  of  the  decision  aids. 

2 . 2 The  TCP  Systeni  and  its  Environment 

The  Marine  Tactical  Combat  Operations  (TCO)  system  is  one  of  eight 
functionally  oriented  tactical  and  training  systems  included  in  the  Marine 
Tactical  ComTiand  and  Control  Systems  (MTACCS)  concept  slated  for  operation 
in  1985.  The  other  seven  are: 

(1)  Marine  Integrated  Fire  and  Air  Support  System  (NIFASS). 

(2)  Marine  Air  Conmand  and  Control  System  - 1985  (MACCS-S5). 

(3)  Marine  Air-Ground  Intelligence  System  (MA61S). 

(4)  Position  Location  Reporting  System  (PLRS). 

(5)  Marine  Integrated  Personnel  System  (MIPS). 

(6)  Marine  Integrated  Logistics  System  (MILOGS). 

(7)  Tactical  Warfare  Simulation  Evaluation  and  Analysis  System 
(TWSEAS). 
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The  TCO  System  supports  commanders  and  their  staff  in  carrying 
out  functions  in  the  areas  of  operations  and  intelligence,  including 
planning,  intelligence  production,  and  the  monitoring  and  directing  of 
tactical  operations.  The  system  provides  this  support  to  ground  elements, 
air  elements,  and  Marine  Air-Ground  Task  Force  (MAGTF)  Headquarters. 

TCO  functions  can  be  grouped  into  five  top-level  functional 

areas: 

(1)  Operational  Support 

(2)  Intelligence  Support 

(3)  Fire  and  Air  Support  . 

(4)  Logistics  Support 

(5)  Personnel  Support 

MTACCS  Interim  Test  Facility.  Alternative  approaches  to  the 
automation  of  MTACC  systems  will  be  tested  on  the  minicomputer-hosted 
MTACCS  Interim  Test  Facility.  The  MTACCS  Interim  Test  Facility  will 
provide  for: 

(1)  The  capability  to  support  the  evaluations  of  automation 
concepts  for  the  TCO  and  other  MTACC  systems. 

(2)  The  representation  of  the  tactical  environment  in  which  the 
MTACC  systems  are  expected  to  function. 

(3)  Control  o1  this  representation  by  means  of  graphic  and 
alphanumeric  terminals  manned  by  Marine  Corps  personnel 
acting  in  an  interactive  man-machine  mode. 

The  MTACCS  Interim  Test  Facility  car.  be  considered  an 
operationally-oriented  laboratory  where  requirements  are  defined,  tested. 
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refined,  and  analyzed  before  they  are  implemented  on  the  battlefield. 

As  such,  it  should  be  an  ideal  test  facility  for  evaluation  of  proposed 
decision  support  systems.  The  software  functions  performed  on  the  MTACCS 
Interim  Test  Facility  are  included  in  Figure  2-1. 

The  exercises  performed  will  consist  of  activities  supported  by 
a sequence  of  events  and  data  inputs  that  emulate  an  actual  military 
operation.  The  scenario  for  the  coming  year  is  based  on  an  infantry 
battalion  as  part  of  a large  force,  i.e..  Marine  Amphibious  Force  (MAF) 
making  an  amphibious  landing  across  the  beach  at  Camp  Pendleton.  This 
constitutes  the  friendly  side  of  the  scenario.  The  Interim  Test  Facility 
will  not  have  any  simulated  air  support.  Consequently,  the  scenario 
picks  up  with  operations  ashore.  The  aggressor  or  enemy  force  will  be 
a mythical  force  tailored  after  likely  adversaries.  All  information 
pertaining  to  the  aggressor  will  be  obtained  from  the  Army  aggressor’s 
handbook.  The  basis  for  definition  of  friendly  forces  will  be  the  Landing 
Force  Operational  System  Study  (LFOSS).  The  LFOSS  is  a document  that 
provides  a description  of  friendly  forces  in  the  future  (e.g.  an  estimate 
of  friendly  forces  fifteen  years  in  advance  can  be  obtained  from  LFOSS). 

2.3  Automated  Information  Management 

2.3.1  General . To  meet  the  requirements  of  modern  computerized  C3 
systems,  Perceptronics  has  developed  and  demonstrated  an  on-line  Adaptive 
Model  for  automatically  selecting  information.  The  model  is  an  extension 
of  on-going  information  management  programs  developed  for  C3  systems 
(Samet,  et  al , 1977),  and  for  advanced  aircraft  operations  (Steeb,  Chen, 
and  Freedy,  1977).  The  model  conceptualizes  messages  or  data  items  as 
multi-dimensional  entities  which  can  be  characterized  by  a set  of 
measurable  attributes.  The  model  computes  an  aggregate  multi-attribute 
evaluation  (MAE)  of  the  message  as  a selection  criterion.  The  model  will 
be  used  to  aid  in  the  transfer  of  tactical  information  among  sources, 
database,  and  users. 
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2.3.2  System  Organization.  Figure  2-2  shows  the  major  components  of 
the  selection  system  in  block  diagram  form.  Three  stages  are  present; 

(1)  determination  of  the  additive  attribute  levels  for  each  message; 

(2)  rescaling  of  the  levels  using  multiplicative  factors;  and  (3)  weighting 
and  aggregation  of  the  constituent  attributes  according  to  the  specific 
user  and  command  situation.  Each  of  these  functions  will  be  treated  in 
turn. 

2.3.3  Attribute  Definition.  The  additive  attributes  are  those  factors 
which  act  in  a trade-off  fashion  (an  increase  in  one  factor  will  compensate 
for  a loss  in  a second  factor)  and  discriminate  between  user  policies. 

As  shown  in  Figure  2-2,  the  attributes  are  derived  from  the  message 
headers  and  from  the  database.  The  attributes  and  their  derivation 
follow: 


Attributes  A.|  to  A^:  content  area.  Each  message  is  categorized 
in  the  header  according  to  content  area.  Approximately  100  numbered 
descriptors  or  data  unit  identifiers  (DUIs)  are  currently  used  for  this 
categorization.  Table  2-1  shows  a subset  of  this  list.  By  analysis, 
the  set  of  DUIs  can  be  partitioned  into  a set  of  4 - 6 meaningfully 
distinct  content  areas  for  each  user.  These  membership  areas  define  the 
content  attributes.  Presence  of  a DUI  in  a given  content  area  results 
in  a unit  level  for  that  attribute,  a zero  level  otherwise. 

Attribute  Ag:  message  age.  The  message  header  lists  the  time 
of  origination  of  the  message.  The  age  is  derived  using  the  system 
clock. 


Attribute  A^:  message  length.  The  number  of  bytes  of  text  is 
obtained  indirectly  from  the  header. 

Attribute  Ag*.  user  familiarity.  The  number  of  times  t^-'  user 
has  seen  the  message.  This  is  maintained  in  an  internal  table. 


ATTRIBUTE 


MULTIPLICATIVE 

MODIFIERS 


WEIGHTING  AND 
AGGREGATION 


DATABASE 

MAE  EVALUATION  ALGORITHM 


FIGURE  2-2 
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TABLE  2-1 


REPRESENTATIVE  DATA  UNIT  IDENTIFIERS 


(1)  World  Area 

(2)  Program  Indicator 

(3)  Installation  Identification  Serial  Number 

(4)  Basic  Encyclopedia  Number 

(5)  Target  System 

(6)  Target  Identification 

(7)  Target  List  Part 

(8)  ABCA  Target  Identity 

(9)  Theater  Target  Number 
(ID)  Document  Source 
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The  multiplicative  factors  are  simply  overall  coefficients  that 
raise  or  lower  the  evaluation  of  a message.  The  multiplicative  form  is 
: required  since  a zero  on  the  factor  level  results  in  a zero  overall 

evaluation.  No  additional  estimation  is  required,  since  each  factor 
influence  is  assumed  invariant  with  respect  to  user  responsibilities  and 
command  situation.  The  factors  and  their  origin  follow: 

Factor  K.| : priority.  Occasionally  a high  priority  tag  is 
assigned  to  a message.  Presence  of  such  a tag  results  in  multiplication 
of  message  importance  (K^>1).  A of  unity  results  otherwise. 

Factor  K2:  accuracy/credibility.  An  accuracy  estimate  is 
I provided  when  unreliable  information  sources  are  used.  0<K2<1.0  provides 

I a suitable  range. 

Factor  K^:  geographic  relevance.  The  geographic  location 
associated  with  a message  is  encrypted  in  a 5 - 7 digit  code  on  the 
header.  This  can  be  matched  with  a coded  listing  of  the  primary 
geographic  responsibility  of  the  user.  Matches  between  header  and  user 
listing  result  in  a unity  value  for  K^,  while  non-matches  result  in  a 
j degradation  of  importance;  C<K2<1 . 

The  above  set  of  additive  attributes  and  multiplicative  factors 
is  considered  to  make  up  a feasible  set.  All  of  the  factors  are  directly 
accessible  from  the  message  headers  and  the  database.  The  set  appears 
; suitable  for  implementation  although  additional  factors  may  be  easily 

added  if  required. 

I 

I 2.3.4  Attribute  Weight  Vector.  Each  user  is  assumed  to  have  a policy 

I of  information  selection  that  depends  on  his  responsibilities  and  on  the 

[ current  command  situation.  This  policy  is  reflected  in  a separate  vector 

of  attribute  weights  for  each  distinct  situation.  For  example,  an 

i 

2-8 

Ll  M 


intelligence  officer  may  have  a high  value  for  political  information 
during  a surveillance  situation  but  less  so  during  an  attack.  Of  course, 
all  combinations  of  user  and  command  situation  need  not  exhibit  a distinct 
weight  vector.  Figure  2-3  shows  how  a given  weight  vector  may  be  common 
to  several  different  command  situations.  Minimizing  the  number  of  weight 
vectors  in  this  fashion  reduces  the  required  training  time. 

Estimates  for  a commander's  attribute  weights,  or  his  utility 
for  that  attribute,  are  provided  by  the  adaptive  portion  of  the  model. 

The  weights  are  learned  (or  trained)  during  sessions  where  a cormiander 
performs  the  tasks  required  in  the  scenario  by  choosing  freely  among  a 
menu  of  possible  information  items.  The  model  begins  with  equal  weights 
assigned  to  each  attribute  and  then  dynamically  adjusts  them  in 
accordance  with  a simple  training  rule. 

The  dynamic  utility  estimation  technique  is  based  on  a trainable, 
multi -category  pattern  classifier.  Figure  2-4  illustrates  the  mechanism. 

As  the  user  performs  the  task,  the  on-line  utility  estimator  observes 
his  choices  among  the  available  information  categories  or  messages,  and 
views  his  decision  making  as  a process  of  classifying  patterns  of 
information  attributes.  The  utility  estimator  attempts  to  classify  the 
attribute  patterns  by  means  of  a linear  evaluation  (discriminant) 
function.  These  classifications  are  compared  with  user's  choices. 

Whenever  they  are  incorrect,  an  adaptive  error-correction  training 
algorithm  is  used  to  adjust  the  utilities.  A comprehensive  discussion 
of  this  technique  can  be  found  in  Freedy,  et  al  (1976),  or  Steeb,  et  al, 
(1977). 

Training  Algorithm.  On  each  trial  or  training  sequence,  the  model 
uses  the  previous  evaluation  weights  (W.)  for  each  attribute  (j)  to  compute 

sJ 

the  multi-attribute  evaluations  (MAE^)  for  each  available  information 
* category  (i). 
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FIGURE  2-4 

SCHEMATIC  REPRESENTATION  OF 
ADAPTIVE  EVALUATION  ESTIMATOR 


PERCEPTRONICS 


The  model  predicts  that  the  user  must  always  prefer  the  available 
information  item  with  the  maximum  MAE  value.  If  the  prediction  is  correct 
(i.e.  the  user  chooses  the  information  item  with  the  highest  MAE),  no 
adjustments  are  made  to  the  utility  weights.  However,  if  the  user  chooses 
a message  having  a MAE  less  than  that  of  the  predicted  message,  the  model 
then  adjusts  the  evaluation  weights  by  pairing  the  chosen  category  with 
the  predicted  category  and  applying  the  error  correction  training 
algorithm.  In  this  manner,  the  evaluator  "tracks"  the  user's  information 
selection  behavior  and  learns  his  utilities  or  weights  for  information 
attributes.  The  training  rule  used  to  adjust  the  weights  associated  with 
each  of  the  attributes  is  illustrated  in  Table  2-2. 


The  training  takes  place  in  response  to  two  types  of  behavior: 

(1)  routing  of  messages  to  the  various  nodes,  and  (2)  viewing  or 
discarding  the  messages  by  the  users.  These  two  functions  are  illustrated 
in  Figure  2-5.  The  first,  routing,  is  shown  in  isolation  in  Figure  2-6. 
Here,  a sequence  of  messages  is  generated  from  the  scenario  file,  each 
with  a distribution  list  of  nodes  to  which  it  will  be  routed.  The 
messages  will  be  treated  two  at  a time  by  the  training  algorithm.  For 
each  node,  the  messages  will  be  evaluated  according  to  the  node's  weighting 
policy.  If  a discrepancy  between  the  predicted  routing  and  the  actual 
routing  occurs,  an  error  correcting  adjustment  will  be  made.  For  example, 
node  1 is  scheduled  to  receive  message  2 but  not  message  3.  If  an 
evaluation  of  the  two  messages  using  node  I's  weights  does  not  correctly 
predict  this  advantage,  a correction  of  the  weight  is  necessary.  In 
abbreviated  form,  the  adjustment  is  as  follows: 


[*^11,  ‘^12’‘"‘^1N- 


new 


[W 


11,  "12’ 


y previous 
'^IN-' 


-X  j ’ ^22  ’ ’ ' ‘ ^2N^  ~ ^^31 ’ ^32 ’ * 


2-12 


TABLE  2-2 


WEIGHT-TRAINING  RULE 


CORRECTION  DIFFERENCE 


* ^ is  a constant  which  influences  the  rate  of  training. 


Chosen  Predicted 

Adjusted  Previous  Adjustment  Information-Source  Information-Source 
Weight  Weight  Factor*  Attribute  Level  Attribute  Level 


Scenario  File 


Message  1 
Message  2 


Message  N 


Routing 


Node  1 
Queue 


Node  2 
Queue 


Node  N 
Queue 


User 

Response 


User 

Response 


User 

Response 


View  Hold  Discard  View  Hold  Discard  View  Hold  Discard 


FIGURE  2-5 

MESSAGE  HANDLING  BEHAVIORS 
IN  INTERIM  TEST  FACILITY 


PERCEPTRONICS 


Continuing  in  the  example,  node  2 is  sent  message  2 but  not  message  1, 
and  node  3 is  sent  message  3 but  not  message  2.  Adjustments  are  made 
to  the  node  2 and  3 weight  vectors  if  the  predictions  are  incorrect.  In 
this  way,  model  predictions  for  each  node  are  evaluated  for  each  pair 
of  messages,  and  systematic  corrections  are  made  for  errors. 

The  second  form  of  behavior,  user  responses  to  the  messages 
received,  results  in  a similar  process  of  observation  and  adjustment. 

As  shown  in  Figure  2-5,  a given  node  will  receive  a sequence  of  messages. 
The  operator  will  either  view  a given  message  or  hold  it  for  later  viewing 
or  discard  it  without  viewing.  The  viewing  is  essentially  an  acceptance 
of  the  routing,  while  the  holding  is  a rejection  of  the  routing.  Each 
pair  of  message  coming  to  a user  is  evaluated  by  the  model  and  a 
prediction  made  as  to  the  relative  importance.  If  the  user  discards  a 
message  of  predicted  high  importance,  and  holds  one  of  low  importance, 
an  error  correcting  adjustment  is  made  as  before. 

These  types  of  adjustment,  according  to  routing  and  according 
to  response,  are  made  in  concert.  Each  adjusts  the  same  sets  of  user 
policy  weights.  The  use  of  two  sources  of  behavior  speeds  the  adjustment 
process  and  provides  inputs  from  both  router  and  user  as  to  distribution 
pol icy. 

2.4  AIS  Functional  Description 

The  AIS  serves  the  following  functions: 

(2)  It  automatically  routes  messages  from  front  line  sources 
to  various  nodes  within  the  system. 

(2)  It  automatically  prioritizes  the  message  queue  for  each 
user  as  command  situations  change. 
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(3)  It  scans  the  database  for  critical  situation  specific 
messages. 

Figure  2-7  illustrates  the  AIS  aiding  of  the  TCO  information  dissemination 
function  during  the  conduct  of  an  exercise  on  the  MTACCS  Interim  Test 
Facility. 

During  a typical  TCO  exercise  on  the  MTACCS  Interim  Test  Facility, 
the  computer  system  serves  the  exercise  players  at  tactical  positions  and 
members  of  the  Control  and  Simulation  Team  (CST)  at  control  positions. 

The  data  processing  system  supports  the  entry  and  transmission  of  messages 
originating  from  both  the  pre-established  simulation  file  and  the  live 
operator  positions.  Exercise  operators  assigned  to  each  tactical  position 
perform  their  normal  military  functions.  They  respond  to  stimuli  from 
other  operators,  from  CST  members  and  from  outputs  of  the  simulation  file. 
The  system  contains  routing  tables  to  control  the  distribution  of 
messages.  The  routing  tables  are  based  on  message  type  and  originating 
node.  They  provide  the  preliminary  distribution  list  for  each  message. 

The  operators  can  add  one  recipient  to  the  message  distribution  list 
without  having  to  change  the  standard  routing  table.  They  possess 
temporary  manual  override  capability  on  the  standard  routing  table  by 
designating  a specific  destination  for  a message  at  the  time  the  message 
is  sent.  Further,  for  each  user,  separate  message  queues  exist  for  each 
message  precedence  category. 

The  Adaptive  Information  Selection  will  aid  the  projected  TCO 
routing  channel  (in  the  performance  of  these  exercises  on  the  test 
facility)  by  automatically  routing  the  messages  and  prioritizing  the 
messages  in  each  user's  queue  by  utilizing  the  multi-attribute  evaluation 
model  approach.  The  specific  functions  of  the  various  elements  of  the 
AIS  as  shown  in  Figure  2-7  are  discussed  below. 
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FIGURE  2-7 

ADAPTIVE  AIS  AIDING  OF  SIMULATED  TCO 
FUNCTIONS  ON  MTACCS  INTERIM  TEST  FACILITY 
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(1)  Message  Attribute  Extractor.  The  message  attribute 
extractor  "extracts"  the  attribute  levels  from  each  message 
(supplied  by  the  pre-established  simulation  file  and  line 
operator  positions)  based  on  its  header,  content  area,  and 
tags.  This  information  is  partly  contained  in  a table 
look-up  format  for  each  message  ID. 

(2)  Familiarity  Indicator.  This  is  a counter  for  determining 
the  number  of  times  specific  users  have  viewed  a particular 
message.  It  assigns  a value  to  the  familiarity  attribute 
level  based  on  this  count. 

(3)  Multiplicative  Modifiers  (MM).  Based  on  message  headers 
resident  in  the  TCO  database,  the  MM  function  outputs  scale 
factors  to  rescale  the  attribute  levels  before  sending  the 
message  to  the  MESSAGE  EVALUATOR.  Two  of  the  MM,  viz 
accuracy  and  cri ticabi 1 i ty  are  user  independent,  whereas 
geographic  location  or  locale  is  a function  of  the  specific 
user. 

(4)  Message  Evaluator  (ME).  The  ME  function  weights  and 
aggregates  the  constituent  attributes  according  to  each 
specific  user  and  command  situation.  Using  a set  of 
multi -attribute  evaluation  (MAE)  models,  it  performs  the 
following  two  functions: 

(a)  It  determines  (1)  distribution  list  of  recipients  (user 
1,  d,  g in  Figure  2-7)  for  each  message  which  it 
recommends  to  the  exercise  operator  (manual  router). 

The  exercise  operator  retains  the  prerogative  to  accept 
or  reject  this  recommendation.  (2)  it  prioritizes  or 
ranks  the  messages  in  each  user's  queue  according  to 
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changes  in  the  command  situation  as  reflected  by 
corresponding  values  in  the  weight  vector  provided  by 
the  WEIGHT  VECTOR  UPDATE  FUNCTION. 


(5)  Weight  Vector  Update  (WVU).  The  WVU  function  selects 
appropriate  weights  per  attribute  for  each  user  as  the 
command  situation  changes. 


3.  EXPERIMENTAL  STUDIES 
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3.1  Automated  Simulators 

It  is  planned  to  subject  the  AIS  to  two  stages  of  exploratory 
testing  in  the  current  year's  work.  The  first  stage  will  entail  automated 
simulations  without  human  subjects.  Sets  of  attribute  vectors  will  be 
generated  and  presented  to  a "model  operator".  The  model  operator  will 
be  programmed  to  make  decisions  according  to  a set  of  pre-set  weights. 
Refinements  of  the  adjustment  rules,  training  procedures,  situation 
structuring,  and  model  form  can  be  made  quickly  and  easily  using  this 
type  of  automated  simulation. 

3.2  Operational  Simulation 

Software  is  currently  being  written  to  use  the  Tactical  and 
Negotiations  Game  (TNG)  as  a preliminary  "gauge-test"  of  the  capabilities 
of  the  AIS.  The  TNG  is  an  in-house  simulation  of  a tactical  message 
distribution  situation.  The  intent  of  this  exercise  is  to  demonstrate 
the  effectiveness  of  the  AIS  in  comparison  with  an  operational  Adaptive 
Aiding  System  (a  precursor  to  the  AIS). 

The  software  of  the  Tactical  and  Negotiations  Game  (TNG)  was 
carefully  reviewed.  It  was  determined  that  its  structure  is  somewhat 
incompatible  with  the  type  of  C3  messages  and  environment  existent  on 
the  Interim  MTACCS  Test  Facility.  The  messages  do  not  contain  the 
pertinent  header  information  necessary  for  proper  discrimination  in  the 
Multi-Attribute-Evaluator  (MAE)  model.  Timing  information  and  distribution 
information  are  similarly  not  available  concerning  the  TNG  messages. 

These  messages  are  currently  being  modified  to  incorporate  this  necessary 
information. 
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The  in-house  operational  simulation  currently  being  implemented 
will  consist  of  two  phases.  The  first  phase  concerns  the  training 
subsystem.  Here,  the  parameters  (user  weights)  for  the  MAE  model  are 
determined  during  a training  session.  These  weights  will  be  specific 
to  the  subject  and  the  command  situation.  The  system  will  display  a pair 
of  randomly  selected  messages  from  the  entire  message  pool  on  the  screen. 
The  subject  will  indicate  his  preference  for  one  of  the  two  messages 
depending  on  his  information  preference  and  the  current  command 
situation.  After  a sufficient  number  of  trials  for  each  command 
situation,  the  subject's  weights  will  converge  to  a stable  set.  At  least 
two  subjects  will  be  trained  before  going  on  to  the  next  phase.  A logical 
description  of  the  Master  Scheduler  for  the  training  subsystem  is 
presented  in  Table  3-1. 

The  second  phase  of  the  operational  simulation  concerns  the 
testing  subsystem.  During  this  phase,  the  testing  will  take  place  to 
determine  if  the  system  trained  weights  conform  to  actual  informational 
preferences.  The  system  will  continually  route  messages  to  at  least  two 
different  subjects.  The  messages  will  eventually  form  a queue  at  each 
subject's  terminal. 

The  system  will  then  select  a message  from  the  visible  queue  to 
present  to  the  subject.  The  subject  can  rate  whether  the  message 
selected  from  the  queue  for  him  was  the  one  he  would  have  preferred  under 
the  given  command  situation.  In  this  manner  during  the  testing  phase, 
the  system  can  gather  statistics  on  how  well  the  MAE  model  was  trained 
to  automate  the  routing  and  prioritizing  function  for  a particular 


subject.  A logical  description  of  the  Master  Scheduler  for  the  testing 
subsystem  is  presented  in  Table  3-2. 


TABLE  3-1 


PDL  - DESCRIPTION  OF  TRAINING  SUBSYSTEM 


Master  Scheduler 


getatt  Read  all  attributes 

Initialize  weight  matrix 

crtset  Initialize  subject  CRT 

For  (COMMAND  SITUATION=l ,N) 

CONVERGr= ' FALSE ' 

While  not(CONVERGE) 

slect2  Select  attribute-vector  pair 

Display  attributes 
Process  subject  response 

trnmau  Conditionally  train  current  weights 

If  (training  occurred) 

normliz  Normalize  weight 

Update  training  statistics 
If  (criteria  met) 

CONVERGE='TRUE' 

Write  weight  matrix  on  a file 
End 
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TABLE  3-2 


getbias 

getatt 

crtset 


route 

subjmon 

subjmon 


POL  - DESCRIPTION  OF  TESTING  SUBSYSTEM 


Master  Scheduler 


Calculate  message  byte-biases 

Read  all  attributes 
Read  weight  matrices 

Initialize  both  CRTs 
Reset  clock  and  statistics 
Get  scenario  from  operator 
(including  optional  control  cases) 

For  (C0NTR0L_CASE*1,  MAX) 

C0MMAND_S1TUATI0N=FIRST 
IF  {COMMAND_SITUATION<LAST 
Sleep  N seconds 
Increment  clock  by  N 
If  (Time  for  next  message) 
Randomly  select  a message 
Route  it 

Monitor  subjectl 
Monitor  subject2 
If  (Time  to  change) 

Get  next  command  situation 

Print  average  rating 


End 
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3.3  Transfer  of  AIS 


It  was  agreed  that  the  best  approach  for  implementing  the  AIS 

at  the  Interim  MTACCS  Test  Facility  would  be  to  recode  the  modules  of 

the  AIS  in  Fortran  at  the  Test  Facility  itself.  The  inhouse  simulation 
is  being  coded  in  the  C language  under  the  UNIX  operating  system.  The 
Test  Facility  uses  a POP  11/70  computer  running  uder  the  IAS  operating 
system.  Perceptronics  has  a POP  11/45  running  under  UNIX  and  does  not 
possess  the  Data  Base  Management  System  (DBMS-11)  used  at  the  Interim 
MTACCS  Test  Facility.  Without  DBMS-11,  no  attempt  can  be  made  to 

i implement  the  entire  AIS  in-house.  The  effort  will  therefore  be 

directed  towards  checking  out  the  individual  modules  of  the  AIS  at 
Perceptronics  and  then  transferring  them  to  the  Interim  MTACCS  Test 
Facility.  The  major  effort  involved  in  implementing  the  AIS  will  be 
I in  interfacing  with  the  existing  software  of  the  test  facility.  This 

I interfacing  is  best  accomplished  at  the  Interim  MTACCS  Test  Facility 

itself.  We  have  received  confirmation  from  personnel  at  Camp  Pendleton 
that  this  is  the  best  approach.  In  this  way,  the  program  effort  can 
1 concentrate  directly  on  the  Marine  application. 

i 

I 

3.3.1  Equipment.  The  MTACCS  Interim  Test  Facility  system  comprising 
a minicomputer  network  will  eventually  consist  of: 

1 DEC  PDP-11/70  minicomputer 
8 DEC  VT-52S  (terminals) 

2 Vector  General  graphic  devices  (CRTs) 

Software.  The  software  for  the  new  MTACCS  Interim  Test  Facility 
system  will  consist  of: 

(1)  A CODASYL-type  database  management  system  (DEC  DBMS-11 
Version  2). 
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(2)  A powerful  and  flexible  operating  system  that  provides  real- 
time, periodic  time-sharing  and  batch  operations  (IAS 
Version  II). 

(3)  Available  languages  include  COBOL,  FORTRAN,  MACRO,  CORAL- 

66. 

3.3.2  TCP  Database  Structure.  The  TCO  database  will  be  a distributed 
database  containing  the  aggregate  of  the  data  stored  at  all  TCO  centers. 
The  distributed  aspect  will  be  transparent  to  the  user.  Applications 
programs  making  up  our  AIS  model  will  access  the  database  and  so  will 
users  through  the  Database  Query  Language.  Our  portion  of  the  database 
will  consist  of  the  tables  for  routing  and  the  data  structures  for  the 
weight  vector  information. 

The  Data  Base  Management  System  greatly  facilitates  the 
organization  and  management  of  information  used  at  the  Interim  MTACCS 
Test  Facility.  It  relieves  the  applications  programmer,  writing  software 
such  as  the  AIS,  from  the  burden  of  having  to  know  the  physical  structure 
of  the  data  base.  The  programmer  would  normally  have  to  use  the 
capabilities  of  the  operating  system  to  perform  all  his  input  and  output. 
This  involves  knowing  all  the  possible  access  methods,  the  proper  syntax 
for  using  these  access  methods  and,  in  general,  very  bothersome  details. 
With  the  Data  Base  Management  System,  the  user  need  have  only  an 
application-oriented  or  logical  view  of  the  data  base  and  not  worry  about 
how  it  is  physically  stored. 

The  Data  Base  Management  System  being  used  by  the  Interim  MTACCS 
Test  Facility  is  Digital  Equipment  Corporation's  DBMS-11  used  on  a PDP 
11/70.  DBMS-11  is  an  implementation  of  the  CODASYL  data  base  language 
specifications.  It  provides  data  base  facilities  for  both  PDP-11  COBOL 
programs  and  programs  written  in  other  languages.  The  DBMS-11  Data  Base 
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Control  System  provides  data  control  and  manipulation  functions  that 
application  programs  use  to  manipulate  data  stored  in  the  data  base.  A 
COBOL  program  invokes  these  functions  through  the  COBOL  Data  Manipulation 
Language  (DML)  statements.  A non-COBOL  program  must  access  these  functions 
via  an  external  subroutine  CALL  statement.  The  generic  interface  program 
which  manipulates  the  data  base  will  be  written  in  COBOL.  This  program 
interfaces  between  the  AIS  which  is  written  in  FORTRAN  and  DBMS-11. 


DBMS-11  supports  both  network  and  hierarchical  types  of  data 
structures  which  are  used  on  the  Interim  MTACCS  Test  Facility.  These 
data  structures  are  defined  using  a language  facility  which  is  part  of 
DBMS-11.  DBMS-11  provides  separate  language  facilities  for  the  description 
of  data  and  for  the  manipulation  of  data.  This  separation  removes  the 
data  description  function  from  the  scope  of  application  programs.  Also, 
the  separation  of  data  description  facilities  allows  integration  of  all 
data  and  data  relations  into  a data  base  that  is  common  to  all  application 
programs  that  use  it.  This  reduces  data  redundancy  and  improves  data 
consistency.  The  data  description  features  of  DBMS-11  provide  for  the 
description  of  the  complete  data  base  and  for  descriptions  of  portions 
of  the  data  base.  The  description  of  the  complete  data  base  is  referred 
to  as  the  schema,  while  the  descriptions  of  portions  of  a data  base  are 
called  subschemas.  While  there  is  only  one  schema  for  a database,  there 
may  be  any  number  of  subschemas,  each  describing  a portion  of  the  data 
base  used  by  one  or  more  applications  programs  such  as  the  AIS. 

A subschema  allows  an  application  program  to  have  access  to  only 
the  particular  part  of  the  data  base  that  concerns  it.  The  Data  Base 
Administrator  (DBA)  creates  the  schema  and  subschemas  using  DBMS-1 I's 
data  description  languages  (DDLs). 

The  following  are  important  concepts  about  schemas  and  subschemas: 
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(a)  The  schema  is  established  independently  of  any  user  program 
or  any  subschema. 

(b)  A subschema  is  a consistent  and  logical  subset  of  the  schema 
from  which  it  is  drawn. 

(c)  Any  number  of  subschemas  can  be  treated  and  are  independent 
of  each  other. 

(d)  A user  program  invokes  a subschema  and  can  reference  only 
those  data  base  records  defined  in  the  subschema. 

Perhaps  the  most  important  feature  of  a data  base  management 
system  is  the  ability  to  support  logical  data  relationships.  It  is  this 
capability  to  relate  record  occurrences  to  one  another  that  reduces 
duplication  of  stored  data  and  provides  direct  access  to  associated 
records.  The  set  is  the  mechanism  by  which  a logical  relationship  is 
established  between  two  or  more  record  types.  It  is  a concept  that  permits 
the  construction  of  a variety  of  data  relationships.  Each  occurrence  of 
a set  includes  one  occurrence  of  an  owner  record  type  and  zero  or  more 
occurrences  of  one  or  more  member  record  types.  Any  record  occurrence 
can  participate  in  any  number  of  set  relationships  as  either  an  owner  or 
member.  This  feature  allows  the  construction  of  complex  integrated  data 
structures. 

A diagram  of  a portion  of  the  schema  definition  for  the  Interim 
MTACCS  Test  Facility  is  shown  in  Figure  3-1.  Each  box  represents  a record 
type  and  the  directed  arrows  define  a set  relationship.  The  tail  of  the 
arrow  touches  the  owner  record  type  and  the  point  of  the  arrow  touches  the 
member  record  type.  The  labels  and  acronyms  on  the  arrows  name  the  set 
relationships  and  provide  information  on  how  the  records  are  ordered 
within  the  set.  They  also  provide  information  on  whether  or  not  new  records 
of  a particular  type  are  automatically  or  manually  included  within  the  set. 
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FIGURE  3-1 

SCHEMA  DEFINITION  FOR  THE  DATA  BASE 
OF  THE  MTACCS  INTERIM  TEST  FACILITY 


PERCEPTRONICS 


This  organization  of  the  data  base  facilitates  intelligent  access 
by  a variety  of  users.  Data  control  and  access  has  evolved  from  the 
earlier  notion  that  each  program  creates  and  manipulates  its  own  data 
independent  of  other  data  that  exists  in  the  computer  system.  The  concept 
of  a data  base,  shared  among  several  programs  concurrently,  places 
additional  requirements  on  the  computer  system  that  has  access  to  that 
database: 

(a)  Data  must  be  accessible  in  a form  and  order  that  is  best 
suited  for  each  individual  program. 

(b)  Data  must  be  concurrently  accessible  to  all  executing 
programs . 

(c)  Data  integrity  must  be  protected  from  undesirable  results 
of  concurrent  access  by  different  programs. 

(d)  Data  must  be  protected  from  unauthorized  access. 

The  DBMS-11  seems  to  provide  access  and  control  of  a data  base  in 
accordance  with  the  above  requirements. 

The  operating  system  designated  for  the  test  facility  is  the 
Interactive  Applications  System  (IAS).  IAS  is  a multi-functional 
operating  system  for  the  PDP  11/70  and  11/45  computers.  It  supports  the 
concurrent  execution  of  three  processing  modes:  Interactive,  Batch,  and 
Real-Time. 

Real-time  applications  operator  on  a priority  basis,  while 
Interactive  and  Batch  jobs  are  time-shared. 
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The  following  is  a breakdown  of  the  costs  of  operating  the  AIS, 
These  costs  involve  the  additional  memory  needed  for  the  software  and 
the  added  response  time  due  to  the  AIS.  In  the  memory  forecast,  (Table 
3-3),  total  cost  is  reflected  in  the  predicted  number  of  lines  of  Fortran 
code  needed  to  implement  each  principal  function.  The  total  number  of 
lines  is  then  translated  into  a memory  estimate  in  bytes.  This  does  not 
include  I/O  routines  or  other  system  functions  which  should  already  be 
in  memory.  In  addition,  the  extra  data  areas  needed  are  given,  such  as 
for  the  attribute  level  tags  associated  with  each  message. 

For  the  response  time  calculations,  a worst  case  example  is  given 
with  the  assumptions  of  a message  pool  of  105  messages  with  eight 
attributes  each  and  three  users  receiving  the  messages.  The  Router  and 
Familiarity  Indicator  programs  should  add  minimally  to  the  response  time 
of  the  AIS  because  much  of  the  code  involved  in  these  routines  should 
already  exist.  Essentially,  the  only  addition  to  response  time  is  due 
to  the  Message  Evaluator  and  Priori tizer.  The  calculations  of  execution 
time  involved  in  these  routines  is  shown  in  Table  3-4. 

As  of  now,  the  worst  case  MCTSSA  estimate  for  message  delay  on 
the  TCO  is  5 seconds  (based  on  former  test  facility),  and  the  amount  of 
memory  allocated  for  the  test  facility  is  300K  bytes.  Our  prediction 
of  the  AIS  response  time  is  about  .05  seconds,  which  compared  to  the 
existing  response  time,  is  negligible.  Also,  the  24K  bytes  of  memory 
needed  for  the  AIS  is  small  compared  to  the  available  storage.  It  appears 
that  the  impact  on  the  system  of  the  added  response  time  and  memory  of 
the  AIS  will  be  minimal. 
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TABLE  3-3.  MEMORY  FORECAST 


Principal  Function  Lines 

of  Fortran  Code 

Critical  Message  Scanner 

150 

Familiarity  Indicator 

100 

Modifier 

100 

Weight  Vector  Updater 

100 

Message  Evaluator 

50 

Prioritizer 

100 

Total  Lines 

600 

Number  of  Bytes 

20K 

Data  Areas 

4K 

TOTAL  MEMORY 

24K 

TABLE  3-4.  AIS  RESPONSE  TIME  (WORST  CASE) 


SAMPLE  105  messages 

8 attributes 
3 users 

MAU  CALCULATIONS: 

105  X 8 X 3 X (l.Ou  sec.  + 2.5p  sec.)  Floating  Pt.  add  & multiply 
- 8.8m  sec.  + lOm  sec.  (overhead  execution  time) 

■ '18. 8m  sec. 

To  prioritize  messages: 

■ 105  X 2. Op  sec.  (for  a compare  & load) 

■ 22m  sec.  + lOm  sec.  (overhead  execution  time) 

■ 32m  sec. 

Total  AIS  response  time  ■ 51m  sec. 
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